ola @mileo @gabrielcardoso21

Acredito que o que levou a esse PR seria a seguinte situação:
"Por exemplo a empresa XPTO tem os seguintes pagamentos a realizar hoje:

1. BOLETO: Lojas.com
2. Pagamento Salário: Fulano
3. DAS: referente ao mês anterior
4. Outra conta da empresa "TED mesma titularidade
5. TED: Para pró-labore do sócio Fulano.
6. GPS: Referente a folha

Na modelagem atual seriam 6 ordens de pagamento, 6 arquivos de remessa.
Fica inviável de usar.
"

Pelo que vi aqui vocês criaram uma forma de agrupar tudo o que é referente ao Pagamento criando um Modo de Pagamento/account.payment.mode que possui dentro o TED, DAS, ISS e Pagamento de Utilitário para que assim seja criada uma Ordem de Pagto única. Achei ruim a implementação basicamente porque dentro de um Modo de Pagamento foi criado um novo objeto account.payment.mode.line que possui os campos name e payment_mode_id, quer dizer que dentro de um Modo de Pagto existem outros Modos de Pagtos, algo que não parece fazer sentido e pode ser confuso de explicar até para o usuário final, acredito que pode existir uma solução melhor, por isso gostaria de fazer algumas perguntas:

Inicialmente pensei que a necessidade seria criar um arquivo de remessa único com as 6 formas mas pelo o que foi feito parece que a necessidade seria apenas de juntar os referentes aos pagamentos (TED, DAS, ISS e Pagamento de Utilitário) sem a necessidade de ter a Cobrança junto na criação do arquivo de Remessa com Lote, seria isso ?

As remessas de Pagamentos são criadas diretamente na tela de Ordem de Pagamento sem um "documento de origem" ( como no caso da cobrança onde a Fatura gera as Linhas da Ordem de Pagto ) e até por isso vocês viram a necessidade de unifica-los e assim facilitar para o usuário final que vai criar apenas uma Ordem de Pagamento ?

Uma possível sugestão que tenho por enquanto baseado no que foi feito seria usar o os campos Code e Payment Type do objeto account.payment.method relacionado para fazer um "domain" e tornar visíveis ou invisíveis os campos referentes a Cobrança/CNAB 240 e 400/inbound ou ao CNAB 240 de Pagto/outbound "limpando" a tela ao deixar apenas os campos específicos de cada um e nesse caso incluindo os campos referentes a TED, DAS, ISS e Pagamento de Utilitário e etc para serem parametrizados, isso é dentro de apenas um Modo de Pagto estariam os campos para configurar o TED, DAS, ISS e Pagamento de Utilitário e etc; seria preciso incluir um campo de tipo Seleção nas linhas de Ordem de Pagto quando fosse o caso do CNAB 240 de Pagto/outbound para permitir a Seleção e identificação de quando é um TED, DAS, ISS e Pagamento de Utilitário e etc, o que vocês pensam sobre isso ?

Algo a se considerar também é se não poderia ser um problema agregar todos essas formas em um único Modo de Pagamento, tanto na solução feita no PR quanto na minha sugestão, por exemplo na utilização de relatórios padrões ou herdados que usam o campo Modo de Pagamento.

cc @renatonlima @rvalyi

ola @mileo @gabrielcardoso21

Acredito que o que levou a esse PR seria a seguinte situação:
"Por exemplo a empresa XPTO tem os seguintes pagamentos a realizar hoje:

1. BOLETO: Lojas.com
2. Pagamento Salário: Fulano
3. DAS: referente ao mês anterior
4. Outra conta da empresa "TED mesma titularidade
5. TED: Para pró-labore do sócio Fulano.
6. GPS: Referente a folha

Na modelagem atual seriam 6 ordens de pagamento, 6 arquivos de remessa.
Fica inviável de usar.
"

Pelo que vi aqui vocês criaram uma forma de agrupar tudo o que é referente ao Pagamento criando um Modo de Pagamento/account.payment.mode que possui dentro o TED, DAS, ISS e Pagamento de Utilitário para que assim seja criada uma Ordem de Pagto única. Achei ruim a implementação basicamente porque dentro de um Modo de Pagamento foi criado um novo objeto account.payment.mode.line que possui os campos name e payment_mode_id, quer dizer que dentro de um Modo de Pagto existem outros Modos de Pagtos, algo que não parece fazer sentido e pode ser confuso de explicar até para o usuário final, acredito que pode existir uma solução melhor, por isso gostaria de fazer algumas perguntas:

Inicialmente pensei que a necessidade seria criar um arquivo de remessa único com as 6 formas mas pelo o que foi feito parece que a necessidade seria apenas de juntar os referentes aos pagamentos (TED, DAS, ISS e Pagamento de Utilitário) sem a necessidade de ter a Cobrança junto na criação do arquivo de Remessa com Lote, seria isso ?

Sim, a cobrança não precisa estar necessariamente junto. A ideia é que o fluxo de pagamentos saída seja unificado.

As remessas de Pagamentos são criadas diretamente na tela de Ordem de Pagamento sem um "documento de origem" ( como no caso da cobrança onde a Fatura gera as Linhas da Ordem de Pagto ) e até por isso vocês viram a necessidade de unifica-los e assim facilitar para o usuário final que vai criar apenas uma Ordem de Pagamento ?

Pare esta prova de conceito sim, mas em um segundo momento as informações deverão vir de outros módulos do sistema, como por exemplo a fatura.

Uma possível sugestão que tenho por enquanto baseado no que foi feito seria usar o os campos Code e Payment Type do objeto account.payment.method relacionado para fazer um "domain" e tornar visíveis ou invisíveis os campos referentes a Cobrança/CNAB 240 e 400/inbound ou ao CNAB 240 de Pagto/outbound "limpando" a tela ao deixar apenas os campos específicos de cada um e nesse caso incluindo os campos referentes a TED, DAS, ISS e Pagamento de Utilitário e etc para serem parametrizados, isso é dentro de apenas um Modo de Pagto estariam os campos para configurar o TED, DAS, ISS e Pagamento de Utilitário e etc; seria preciso incluir um campo de tipo Seleção nas linhas de Ordem de Pagto quando fosse o caso do CNAB 240 de Pagto/outbound para permitir a Seleção e identificação de quando é um TED, DAS, ISS e Pagamento de Utilitário e etc, o que vocês pensam sobre isso ?

Sim, foi isso que implementamos, entretanto a visão ainda não foi customizada para cada caso.

Algo a se considerar também é se não poderia ser um problema agregar todos essas formas em um único Modo de Pagamento, tanto na solução feita no PR quanto na minha sugestão, por exemplo na utilização de relatórios padrões ou herdados que usam o campo Modo de Pagamento.

cc @renatonlima @rvalyi

ola @mileo

"Sim, foi isso que implementamos, entretanto a visão ainda não foi customizada para cada caso." A sugestão que fiz seria sem o objeto account.payment.mode.line e a necessidade de ter Modos de Pagamento dentro de um Modo de Pagamento.

Mas como a resposta sobre o "documento de origem" foi "Pare esta prova de conceito sim, mas em um segundo momento as informações deverão vir de outros módulos do sistema, como por exemplo a fatura." é isso seria incluir dois Modos de Pagamentos a serem selecionados pelo usuário o Modo Principal e a linha que seria outro Modo de Pagamento ou !?!? o mesmo !?!?! ( ex.: no caso Cheque e !?!? Cheque !?!? ou Boleto X e !?!? Boleto X !?!? ), algo que parece não fazer muito sentido escolher dois modos de pagamentos, por isso eu acredito que podemos tentar abordar o problema de outra forma:

Minha sugestão seria criar no Diário/Account Journal ( acredito que em comum todos esses Modos de Pagamento devem usar o mesmo Diário ) um boolean ex.: "Gerar Arquivo de Remessa com Lotes", quando a opção estiver marcada ao criar uma nova Ordem de Pagamento também seria criado um novo objeto ex.: CNAB.REMESSA.LOTES em uma estrutura semelhante ao que existia na importação l10n_br.cnab/l10n_br.lote/l10n_br.evento mas nesse caso seria ESSE_NOVO_OBJETO/payment.order/payment.order.line assim as linhas desse novo objeto seriam as Ordens de Pagamento, isso ficaria transparente ao usuário, ele poderia acessar pelo menu apenas esse novo objeto, seria preciso sobre escrever os métodos de mudanças de status na Ordem de Pagamento e criar um campo/link/one2many para redirecionar para esse novo objeto, aparentemente isso parece atender o problema e juntaria tantos os boletos quanto os pagamento sem a necessidade de grandes alterações em objetos,métodos e visões herdadas. O que vocês pensam sobre isso ?

@mbcosta, bom dia.

Obrigado pelas sugestões, o que você disse faz bastante sentido. Penso que não é realmente necessário criar um novo objeto para o arquivo com mais de um lote do CNAB 240, visto que a única diferença do agrupamento é que se colocam mais lotes dentro do mesmo arquivo. Essa diferenciação pode confundir o usuário e acabar atrapalhando ao invés de ajudar. Sobre a eliminação do account.payment.mode.line, concordo que a nomenclatura do modelo pode levar a confundir os conceitos, e aceito sugestões de mudança. Continuo preferindo, porém, que o modelo com essa função continue existindo, pois essa abstração pode ser usada em outros casos para resolver problemas similares. Sugiro também que seja incluído no modelo um campo many2many com o modelo ir.model.fields, com o domínio filtrando os campos da linha de pagamento, para que se possa escolher dinamicamente quais campos esconder se esse tipo de pagamento for selecionado.

ola @gabrielcardoso21 , alterar a nomeclatura do objeto account.payment.mode.line não vai alterar o fato de que dentro dele ser feita uma ligação com outro account.payment.mode https://github.com/odoo-brazil/l10n-brazil/blob/feature/cnab-multiple-payments/l10n_br_account_payment_order/models/account_payment_mode_line.py#L17 o que significa ter dentro de um Modo de Pagamento outros Modos de Pagamentos.

"Continuo preferindo, porém, que o modelo com essa função continue existindo, pois essa abstração pode ser usada em outros casos para resolver problemas similares. " Quais ?

Tenho outra sugestão para resolver esse problema que acredito que vai atender as especificações:

• Criar um campo ex.: cnab_lot do tipo Boolean dentro do objeto account.payment.mode ( melhor do que dentro do Diário como havia sugerido antes por permitir diferentes configurações )

• Criar um campo ex.: lot_payment_mode_ids do tipo many2many dentro do objeto account.payment.order

• Criar um campo ex.: payment_mode_id do tipo many2one dentro do objeto account.payment.line ( e outros "related" com o "store=True" que precisem ser registrados )

• Quando for criada uma Ordem de Pagamento e o Modo de Pagto tiver marcado com o campo boolean deixamos invisível o campo payment_mode_id ( original do modulo account_payment_order ) no account.payment.order e visível o campo lot_payment_mode_ids mostrando na visão/tela ao usuário que aquela Ordem de Pagto é composta de mais de um Modo de Pagto e na criação da linha/account.payment.line preenchemos o payment_mode_id do objeto account.payment.line

• Ao criar essa nova Ordem o programa deverá buscar se já existe alguma com o mesmo Diário/account.journal e com o Modo de Pagto com o boolean preenchido( acredito que também será preciso usar como filtro o Metodo de Pagto, a confirmar, pois isso fará com que não seja possível unificar as Cobrança/Ordens de Débito com os Pagamentos/Ordens de Credito ), se sim será apenas adicionado na Ordem de Pagmento existente o Modo de Pagamento no campo many2many e na criação da account.payment.line o campo payment_mode_id podendo assim diferenciar os Modos de Pagamento

Dessa forma teremos seis Modos de Pagamentos porém somente uma Ordem de Pagamento e um arquivo de Remessa, o que pensam sobre isso ?

ola @gabrielcardoso21 , alterar a nomeclatura do objeto account.payment.mode.line não vai alterar o fato de que dentro dele ser feita uma ligação com outro account.payment.mode https://github.com/odoo-brazil/l10n-brazil/blob/feature/cnab-multiple-payments/l10n_br_account_payment_order/models/account_payment_mode_line.py#L17 o que significa ter dentro de um Modo de Pagamento outros Modos de Pagamentos.

"Continuo preferindo, porém, que o modelo com essa função continue existindo, pois essa abstração pode ser usada em outros casos para resolver problemas similares. " Quais ?

Tenho outra sugestão para resolver esse problema que acredito que vai atender as especificações:

• Criar um campo ex.: cnab_lot do tipo Boolean dentro do objeto account.payment.mode ( melhor do que dentro do Diário como havia sugerido antes por permitir diferentes configurações )
• Criar um campo ex.: lot_payment_mode_ids do tipo many2many dentro do objeto account.payment.order
• Criar um campo ex.: payment_mode_id do tipo many2one dentro do objeto account.payment.line ( e outros "related" com o "store=True" que precisem ser registrados )
• Quando for criada uma Ordem de Pagamento e o Modo de Pagto tiver marcado com o campo boolean deixamos invisível o campo payment_mode_id ( original do modulo account_payment_order ) no account.payment.order e visível o campo lot_payment_mode_ids mostrando na visão/tela ao usuário que aquela Ordem de Pagto é composta de mais de um Modo de Pagto e na criação da linha/account.payment.line preenchemos o payment_mode_id do objeto account.payment.line
• Ao criar essa nova Ordem o programa deverá buscar se já existe alguma com o mesmo Diário/account.journal e com o Modo de Pagto com o boolean preenchido( acredito que também será preciso usar como filtro o Metodo de Pagto, a confirmar, pois isso fará com que não seja possível unificar as Cobrança/Ordens de Débito com os Pagamentos/Ordens de Credito ), se sim será apenas adicionado na Ordem de Pagmento existente o Modo de Pagamento no campo many2many e na criação da account.payment.line o campo payment_mode_id podendo assim diferenciar os Modos de Pagamento

Dessa forma teremos seis Modos de Pagamentos porém somente uma Ordem de Pagamento e um arquivo de Remessa, o que pensam sobre isso ?

@mbcosta realmente essa solução resolve os problemas sem perdas na usabilidade. Tendo um tempo vejo se consigo implementar. Obrigado, novamente, pelas sugestões.